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ABSTRACT 

ARAPAIMA  is  a  proximity  operations  mission  sponsored  by  the  US  Air  Force  Office  of  Scientific  Research 
(AFOSR)  and  the  Air  Force  Research  Faboratory  (AFRF),  to  perform  the  in-orbit  demonstration  of  autonomous 
proximity  operations  for  visible,  infrared,  and  point  cloud  generation  of  resident  space  objects  (RSOs)  from  a 
nanosat  platform.  The  nanosat  is  of  the  6U  CubeSat  class,  with  overall  dimensions  of  12x24x36cm,  a  mass  of 
9.78kg,  and  has  been  selected  as  part  of  AFRL’s  University  NanoSat  Program  (UNP)  Cycle  8.  This  paper  describes 
the  mission  goals,  concept  of  operations,  science  objectives  and  subsystem  design  and  selection,  with  focus  given  to 
a  detailed  mission  analysis  and  the  requirements  flow-down. 

By  demonstrating  robust,  affordable,  and  responsive  rendezvous  and  proximity  operations  of  a  nanosat  with  an 
uncooperative  RSO,  successful  completion  of  the  ARAPAIMA  mission  will  validate  a  range  of  technologies  for 
space-based  space  12situational  awareness  (SSA)  and  debris  removal  from  Fow  Earth  Orbit  (FEO).In  addition,  the 
mission  will  validate  a  set  of  key  technologies  and  their  integration  at  system  level,  such  as  miniaturized 
commercially  available  sensors,  a  miniaturized  warm  gas  propulsion  system  for  CubeSat  applications,  as  well  as 
advanced  relative  navigation  and  proximity  operations  algorithms  implemented  on  a  nanosat. 

MISSION  OPERATIONS  CONCEPT/OVERVIEW 

ARAPAIMA  stands  for  “Application  for  RSO 
Autonomous  Proximity  Analysis  and  IMAging”. 

ARAPAIMA  is  a  proximity  operations  mission 
sponsored  by  the  US  Air  Force  Office  of  Scientific 
Research  (AFOSR)  and  the  Air  Force  Research 
Faboratory  (AFRF),  through  the  University  Nanosat 
Program,  to  perform  the  in-orbit  demonstration  of 
autonomous  proximity  operations  for  visible,  infrared, 
and  three  dimensional  imaging  of  resident  space  objects 
(RSOs)  on  a  cubesat  platform. 

The  payload  consists  of  a  commercially  available 
infrared  (IR)  camera  and  a  miniature  laser  rangefinder 
(FRF)  with  a  range  of  a  few  km.  The  instruments  are 
installed  on  the  cubesat  so  that  their  optical  axes  are 
pointing  in  the  same  direction.  The  cubesat  is  equipped 
with  a  warm  gas  propulsion  system  which  enables  it  to 
perform  orbital  maneuvering  and  reaction  control  of 
attitude.  The  goal  of  the  ARAPAIMA  mission  is  to 
perform  the  in-orbit  demonstration  of  autonomous 
proximity  operations  for  visible,  infrared,  and  three 
dimensional  imaging  of  RSOs.  ARAPAIMA  is  of  the 


6U  cubesat  class  with  overall  dimensions  of 
12x24x3 6cm.  The  ARAPAIMA  cubesat  can  be  seen  in 
Figure  1. 


Double-deployable  6U  solar  panel 


Deployable  3U  solar  panel 


Reaction  wheel 


Figure  1:  CAD  model  of  the  ARAPAIMA  Cubesat 
Mission  Concept  of  Operations 

The  in-orbit  operations  of  ARAPAIMA  and  specific 
proximity  operation  scenarios  can  be  broken  down  into 
five  steps.  Each  of  the  five  mission  steps  is  tied-in  with 
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an  objective  of  increasing  complexity  and  science 
returns.  The  mission  concept  of  operations  (ConOps) 
can  be  seen  in  Figure  2.  This  figure  shows  a 
"cartoonized"  and  simplified  outline  of  the 
ARAPAIMA  mission. 
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Figure  2:  ARAPAIMA  Concept  of  Operations 

Achievement  of  each  objective,  within  selected 
tolerances,  clears  the  mission  to  proceed  to  the  next 
step.  At  the  completion  of  each  step  the  cubesat  enters  a 
"telecom  mode"  in  which  the  attitude  is  commanded  so 
that  the  antennas  of  the  communications  subsystem 
point  in  the  nadir  direction.  The  ground  control  team 
verifies  successful  completion  of  each  step  and 
downloads  the  data  products  generated  during  the  step, 
including  the  house  keeping  data.  Once  the  ground 
control  team  verifies  the  successful  completion  of  the 
step  it  issues  an  authorization  to  precede  (ATP) 
command  to  the  cubesat.  While  deorbiting  the  cubesat 
is  left  out  of  the  mission  objectives;  it  is  a  critical 
objective  for  a  fully  successful  mission.  Simulations  for 
mission  planning  will  take  into  account  that  propellant 
should  be  allocated  for  a  deorbiting  maneuver.  The 
mission  is  considered  successful  after  the  cubesat 
reenters  the  atmosphere  and  disintegrates. 

Science  Concepts  of  Operation 

The  ConOps  for  ARAPAIMA  science  is  illustrated  in 
Figure  3.  Extensive  guidance,  navigation  and  computer 
vision  algorithm  development  will  be  needed  to  ensure 
mission  success. 


Figure  3:  ARAPAIMA  Science  ConOps 

The  science  ConOps  shows  a  almost  step-by-step 
recreation  of  the  mission  from  a  science  point-of-view. 
It  demonstrates  the  many  successes  that  must  take  place 
in  order  to  ensure  mission  success.  Among  these 
successes  are  many  new  technologies  and  methods. 

PROGRAM  SCOPE/MISSION  OBJECTIVES 

Mission  Objectives 

1.  Determine  the  3-D  shape  of  the  RSO  without 
previous  knowledge. 

2.  Autonomously  navigate  and  safely  maneuver 
in  close  proximity  to  the  RSO,  in  low  earth 
orbit. 

3.  Estimate  the  attitude  state  of  the  RSO  by 
remote  observation. 

The  mission  objectives  are  achieved  in  five  steps  of 
increasing  complexity.  During  the  first  two  steps  the 
cubesat  is  commanded  by  ground  control  to  maneuver 
within  LRF  range  of  the  RSO  and  acquire  a  relative 
circular  orbit  with  respect  to  it.  The  third  step  consists 
of  ARAPAIMA  maneuvering  autonomously  to  reduce 
the  size  of  the  relative  orbit  to  a  few  hundred  meters  by 
applying  Angles  Only  Navigation  (AON)  techniques. 
The  fourth  step  will  perform  visible  and  IR  passive 
imaging  of  the  RSO.  During  the  fifth  step  a 
combination  of  chaser  attitude  motion  and  relative 
motion  between  the  cubesat  and  the  RSO  is  employed 
to  perform  3D  imaging  of  the  RSO  by  combining  LRF 
measurements  and  knowledge  of  the  cubesat  inertial 
attitude  and  position.  Successful  completion  of  the 
mission  validates  a  range  of  technologies  that  can  be 
used  for  debris  removal  from  low  Earth  orbit  by 
demonstrating  robust,  affordable,  and  responsive 
rendezvous  of  cubesats  with  uncooperative  RSOs,  on  a 
budget  two  orders  of  magnitude  lower  than  previous 
observer  missions  such  as  XSS-11  (AFRL)  and  Orbital 
Express  (DARPA). 
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Mission  Success  Criteria 

It  is  the  decision  of  the  team  with  close  guidance  by  the 
University  Nanosatellite  Program  (UNP)  Program 
Office  (PO)  to  not  only  define  the  full  and  minimum 
success  criteria,  but  also  the  extended  success  criteria. 
This  allows  for  achievable  minimum  and  full  success, 
while  also  correctly  portraying  the  mission  and  the 
mission  goals  as  a  whole. 

1.  Minimum  mission  success  is  achieved  by 
successfully  taking  an  unresolved  image  of  the 
RSO  and  downlink  it  to  the  ground  station 

2.  Full  mission  success  is  defined  by  the 
statement: 

Maneuver  the  nanosat  into  the  proximity  of  the 
RSO  with  commands  generated  by  the  mission 
operators,  and  take  an  image  in  which  the  RSO 
occupies  at  least  15\%  of  the  pixels  of  the 
visible  and  IR  spectrum  cameras 

3.  Extended  mission  success  is  achieved  by 
meeting  the  following  criteria: 

On-board  planning  and  execution  of 
maneuvers  to  acquire  a  relative  orbit  with 
respect  to  the  RSO  and  use  range 
measurements  to  generate  a  3D  point  cloud 

Mission  Phases 

1)  Maneuver  within  LRF  range  (less  than  2km)  from 
the  RSO  using  pre-loaded  commands:  After  separation 
from  the  launcher,  detumbling,  and  systems  check, 
ARAPAIMA  is  authorized  to  perform  the  first  step. 
During  this  step,  the  cubesat  approaches  the  RSO  to  a 
distance  just  below  2km.  The  cubesat  is  commanded  to 
point  the  payload  at  the  RSO  and  take  visible  and  IR 
images  and  LRF  ranges  to  confirm  the  successful 
execution  of  the  step.  2)  Acquire  a  relative  circular 
orbit,  with  respect  to  the  RSO,  of  less  than  2km  radius 
using  pre-loaded  commands:  Once  the  verification  of 
the  relative  distance  is  completed,  an  ATP  from  the 
ground  station  is  issued,  and  the  cubesat  uses  pre- 
loaded  commands  to  acquire  a  circular  relative  orbit 
with  the  RSO.  The  radius  of  relative  orbit  is  within  LRF 
range,  and  similarly  to  the  first  step,  after  completion  of 
the  maneuvers  the  cubesat  uses  its  cameras  for  RSO 
imaging  and  the  LRF  to  confirm  its  range.  Additionally, 
the  attitude  is  commanded  so  that  the  payload  tracks  the 
RSO  as  ARAPAIMA  orbits  it.  The  ground  control  team 
issues  an  ATP  after  confirmation  of  relative  orbit 
acquisition,  and  the  cubesat  proceeds  to  the  next  step. 
3)  Maneuver  autonomously  to  reduce  the  size  of  the 
relative  orbit  to  below  a  few  hundred  meters:  The  third 
step  starts  with  the  cubesat  acquiring  the  RSO  with  its 
visible  and  IR  cameras  and  using  the  LRF  to  perform 
periodic  ranging.  The  orbits  of  both  the  RSO  and  the 
cubesat  are  propagated  on  board  the  cubesat,  and  a 


propellant  optimal  maneuver  is  computed  to  take  the 
cubesat  into  a  tighter  relative  circular  orbit.  During  the 
inactive,  nonthrusting  arcs  of  the  reconfiguration 
trajectory  the  cubesat  periodically  acquires  the  RSO 
with  the  cameras,  and  it  takes  LRF  measurements  and 
GPS  solutions  to  verify  the  accuracy  of  the  OMT 
maneuvers  and  ensure  operational  safety.  Operations 
during  the  third  step  are  defined  as  autonomous  because 
the  orbital  and  attitude  maneuver  commands  are 
generated  on  board  the  cubesat  instead  of  being  pre- 
loaded  by  ground  control.  The  team  emphasizes  that  the 
autonomous  maneuvers  performed  during  the  proximity 
operations  will  be  designed  for  simplicity  and 
robustness.  The  maneuvers  will  be  fully  validated  on  a 
high  fidelity  real-time  mission  simulation  test-bed 
throughout  the  lifetime  of  the  mission  during 
preparatory  sessions.  At  the  end  of  the  third  step,  the 
cubesat  lies  in  a  circular  orbit  of  250m  diameter  relative 
to  the  RSO.  4)  Perform  autonomous  visible  and  IR 
imaging  and  LRF  reflectivity  measurements  of  the 
RSO:  After  successful  completion  of  the  third  step  and 
receiving  the  ATP,  the  cubesat  proceeds  with  the  fourth 
step  during  which  it  is  tasked  to  perform  autonomous 
imaging  of  the  RSO  and  to  autonomously  plan  relative 
orbit  maintenance  maneuvers  to  offset  the  effects  of 
differential  drag,  J2,  and  solar  radiation  pressure  (SRP). 
Images  taken  in  the  visible  and  IR  spectra  will  be  used 
by  the  team  to  inspect  the  RSO  and  determine  any 
outstanding  features.  Once  a  certain  number  of 
observations  are  made,  the  cubesat  enters  its  telecom 
mode  to  download  the  data  to  the  ground  station.  Upon 
analysis  of  the  imaging  data,  the  ground  control  team 
decides  to  issue  the  ATP  to  the  fifth  step.  5)  Perform 
3D  imaging  of  the  RSO  using  a  combination  of  attitude 
motion  and  relative  motion,  with  respect  to  the  RSO, 
and  combine  LRF  measurements  and  knowledge  of  the 
cubesat’ s  inertial  attitude  and  position  to  generate  point 
clouds.  5a)  Open  outer  loop  control  of  attitude:  Pre¬ 
programmed  attitude  profiles  are  used,  which  command 
the  cubesat  to  perform  an  up-and-down  scanning 
motion  or  a  slow  spiral  with  respect  to  the  RSO.  A 
coarse  attitude  state  of  the  RSO  with  respect  to  the 
chaser  body  frame  can  be  estimated  and  transformed  to 
an  inertial  frame  based  on  the  attitude  solution  of  the 
chaser.  Point  clouds  of  larger  resolution  resolve  the 
features  of  the  RSO  and  can  be  used  to  determine  their 
relative  locations  with  respect  to  the  chaser  body  frame. 
Based  on  the  information  extracted  from  the  point 
clouds,  RV  and  docking  paths  can  be  planned  on-board, 
and  the  chaser  is  commanded  to  follow  them  up  to  a 
safe  distance  to  the  RSO.  End-to-end  simulations  of  the 
scanning  phase  of  the  mission  will  be  employed  to 
determine  which  parts  are  better  performed 
autonomously  and  which  are  better  performed  by  pre- 
loaded  commanding.  These  methods  are  also  applicable 
to  3D  imaging  of  tumbling  or  maneuvering  RSOs.  5b) 
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Closed  outer  loop  control  of  attitude:  The  IR  camera  is 
used  to  capture  images  of  the  LRF  bloom  on  the  surface 
of  the  RSO  and  close  the  outer  attitude  control  loop 
according  to  some  coverage  criterion.  To  close  the 
outer  attitude  loop  with  the  IR  camera  a  three -part 
algorithm  is  employed  to  detect  and  close  gaps  in  LRF 
strike  point  coverage  on  the  RSO.  Gap  detection  is 
achieved  using  Voronoi  diagrams  in  which  Voronoi 
cells  are  centered  at  the  LRF  strike  points.  Time 
stamped  range  measurements  of  each  LRF  strike  point 
are  registered  to  the  image  taken  by  IR  camera.  The 
implementation  relies  on  the  fact  that  an  area  of  sparse 
or  no  coverage  has  one  or  more  Voronoi  points  whose 
"empty  circle,"  centered  at  the  Voronoi  point  and 
containing  no  strike  points  is  large  relative  to  the  other 
empty  circles  in  the  diagram.  This  enables  the  detection 
of  a  gap  and  its  marking  for  every  image  that  makes  up 
the  original  spherical  projection.  The  nearest  detected 
gap  on  the  projection  of  the  path  of  the  chaser  on  the 
RSO  satellite  is  computed,  and  it  is  used  to  generate  a 
slew  command  toward  the  center  of  the  gap.  The  chaser 
triggers  the  LRF  to  cover  the  gap  with  strike  points. 
Once  the  chaser  "over  flies"  the  gap,  the  map  is  updated 
with  the  new  strike  points,  gaps  are  re-computed,  and  a 
new  gap  is  prioritized  for  targeting. 

Mission  Operational  Modes 

The  operational  modes  of  the  proposed  payload  are 
described  in  Figure  4.  The  operational  modes  can  be 
thought  of  as  states  of  a  finite  state  machine  (FSM),  the 
nanosat.  The  nanosat  is  in  only  one  state  (mode)  at  a 
time  and  it  can  transition  to  another  mode  only  if 
certain  conditions  are  met. 


Mode 

Name 

Duration 

Description 

■  S/C  is  in  the  pod  and  an  systems  are  oft 

l 

P-POD 

Store 

TBD 

Entry  :  S/C  enters  this  mode  when  it  is  inteerated  mto  the  P-POD  by  the 
latmch  facility  personnel 

2 

Deployed 

45min. 

Xommal  exit:  The  S/C  exits  this  mode  when  the  P-POD  door  is  opened 
and  it  is  released 

•  The  S/C  has  been  released  from  die  P-POD  and  it  is 

•  The  initial  tumbling  (tip-off)  rates  are:  5deg,  s  per  axis 

■  Some  power  is  available  from  the  solar  panels. 

•  Deploy  soiar  panels 

•  The  OBC  is  booted  up. 

•  The  payload,  propulsion,  thermal  control,  ADCS,  and  comm 
subsystems  are  turned  on  for  the  initial  check 

Entry  A  pressure  switch  or  more  is  thrown  on. 

3 

De  tumble 

30  min. 

Xommal  exit:  After  the  initial  sub-systems  check. 

•  The  S/C  cancels  the  angular  rates  about  all  axes 

•  "The  power  source  is  the  solar  panels 

•  IMU  rate  gyros  are  the  primary  attitude  determination  sensors. 

•  RCS  thrusters  are  employed  to  detumWe. 

•  Sun  acquisition  through  solar  panels  to  charge  batteries. 

Entry:  At  the  nominal  exit  from  the  deployed  mode. 

Xommal  exit:  After  the  angular  rates  have  been  reduced  to  a  value  of 

TBD  de  g  s  about  each  axis. 

4 

System 

Cheek 

TBD 

•  Individual  and  multiple  subsystem-check  -  die  S/C  is  put  through  a 
checklist 

•  S/C  establish  link  with  ground  station  and  downlinks  its  status. 

Entry  At  nominal  exit  from  d stumble  mode 

.Vominal  e.vrf:  After  verification  from  ground  station. 

•  Under  command  from  ground  station.  S  C  will  execute  orbital 
maneuvers  to  approach  within  2km  of  the  target  satellite. 

•  OMT  used  for  maneuvering. 

•  For  relatively  large  av  manoeuvers  the  nanosat  might  be  spin 
stabilized. 

•  For  relatively  small  av  manoeuvers  the  nanosat  might  be  spm 
stabilized. 

5^ 

— --SJar  trackers  are  the  primary  attitude  determination  sensors. 

.  station 


Figure  4:ARAPAIMA  Operational  Modes 

At  this  stage  of  the  mission  design,  the  operational 
modes  are  used  to  derive  power  budgets  and  data 
budgets.  Towards  the  end  of  the  preliminary  design 
phase  the  operational  modes  defined  here  will  be 
implemented  in  MATLAB/Simulink/Stateflow  and  will 
be  used  as  a  master  mission  script  during  simulations. 

The  team  has  also  defined  nominal  and  entry  conditions 
and  will  commence  working  on  off-nominal  entry  and 
exit  transitions.  A  total  of  1 1  modes  have  been  defined 
and  they  are  enumerated  below.  A  snapshot  of  the 
operational  modes  table  is  presented  in  Figure  4  to 
show  its  structure.  The  operational  modes  are: 

1 .  the  P-POD  store  mode  during  which  the 
nanosat  is  stored  in  the  P-POD  and  awaiting 
launch  -  the  nominal  exit  takes  place  when  the 
P-POD  door  is  open  and  the  nanosat  is 
released  from  the  launcher; 

2.  the  deployed  mode  during  which  the  nanosat  is 
tumbling  after  release  from  the  P-POD  -  the 
solar  panels  are  deployed  after  a  certain 
amount  of  time  and  the  mode  is  exited  after 
the  OBC  is  booted  up; 

3.  the  detumble  mode  during  which  the  nanosat 
uses  the  rate  gyros  of  the  IMU  and  its  RCS 
thrusters  to  cancel  the  angular  rates  about  each 
axis  -  the  mode  is  exited  nominally  if  the 
angular  rate  about  each  axis  has  been  brought 
below  a  certain  threshold,  the  largest  solar 
panel  has  been  pointed  towards  the  Sun,  and 
the  telecom  antennas  are  pointing  in  the  nadir 
direction; 
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4.  the  system  check  mode  during  which  the  OBC 
commands  the  nanosat  subsystems  to  perform 
tasks  with  well  understood  and  defined  input- 
output  relationships  -  the  mode  exits 
nominally  upon  ATP  from  ground  control; 

5.  the  ground  control  RSO  approach  mode  during 
which  the  nanosat  performs  pre-loaded  orbital 
maneuvers  to  approach  the  target  and  acquire 
relative  orbit  which  respect  to  it  -  the  mode  is 
exited  nominally  upon  termination  of  the 
orbital  maneuver  and  ATP  from  ground 
station; 

6.  the  science  operations  mode  during  which  the 
nanosat  performs  visible  and  IR  spectrum  and 
3D  imaging  of  the  RSO  -  the  mode  is  exited 
nominally  upon  command  from  the  OBC  to 
perform  relative  orbit; 

7.  the  relative  orbit  maintenance  mode  during 
which  the  nanosat  performs  pre-loaded  orbital 
maneuvers  to  offset  the  effect  of  differential 
drag,  J2,  and  SRP  -  the  mode  is  exited 
nominally  upon  successful  execution  of  the 
maneuvers  and  ATP  from  ground  control; 

8.  the  comms  mode  during  which  the  nanosat  is 
pointed  such  that  the  telecom  antennas  are  in 
the  nadir  direction  -  the  mode  is  exited 
nominally  upon  ATP  from  ground  control; 

9.  the  collision  avoidance  mode  during  which 
upon  command  from  ground  control  or  from 
the  OBC  the  nanosat  performs  a  separation 
maneuver  -  the  mode  is  triggered  by  detection 
of  anomalous  orbital  parameters  of  the  nanosat 
which  would  put  it  on  path  that  penetrates  the 
safety  sphere  centered  at  the  RSO  -  the  mode 
is  exited  after  ground  control  verifies  the 
collision  danger  subsided  and  the  issues  an 
ATP; 

10.  the  deorbit  mode  during  which  the  nanosat 
lowers  is  perigee  so  that  it  will  reenter  the 
atmosphere  and  disintegrates  -  the  mode  does 
not  have  an  exit  but  it  ends  when  the  nanosat 
has  been  confirmed  reentered; 

11.  the  safe  mode  is  designed  to  protect  the 
payload  and  nanosat  subsystems  -  it  is  likely 
that  in  this  mode  the  nanosat  slowly  spins 
about  it  major  axis,  the  payload  instruments 
point  away  from  the  Sun  -  the  mode  is  exited 
upon  ATP  from  ground  control. 

The  modes  have  been  kept  under  a  dozen  as  this  stage 
of  the  mission  design.  Later  on,  as  the  concept  of 
operations  mature,  more  modes  will  be  added.  For 
example,  relative  orbit  maintenance  and  exit  from  the 
safe  mode  can  be  performed  either  with  pre-loaded 
commands  or  autonomously.  The  modes  table  will  be 
extended  to  include  both  types  of  modes. 


CUSTOMERS 

The  mission  already  has  six  confirmed  customers,  three 
from  each  of  the  Air  Force  Research  Laboratory 
(AFRL)  Space  Vehicles  Directorate  and  from  the 
NASA  Goddard  Space  Flight  Center.  The  customers  are 
interested  in  either  the  data  products,  i.e.,  images  and 
3D  point  clouds  of  the  RSO,  or  in  testing  algorithms 
on-board  the  nanosat. 

AFRL 

Dr.  Brian  Fie  welling,  AFRL/RVSV,  is  currently 
engaged  in  multiple  aspects  of  space-based  SSA.  The 
images  captured  and  downlinked  by  ARAPAIMA  will 
be  used  in  the  AFRL/RVSV's  Sensor-based  Control  of 
Relative  Motion  (SCReAM)  laboratory  to  test  and 
validate  multi-resolution  techniques  in  spacecraft 
characterization  and  relative  pose  determination. 

Dr.  Josue  Munoz  and  Mr.  Nathan  Stastny,AFRL/RVES, 
provide  support  to  the  AFRL  in  simulations  and 
military  utility  assessment  of  several  ongoing  and 
future  flight  missions.  Their  interest  in  the  ARAPAIMA 
missions  is  focused  on  the  on-orbit  demonstration  of 
guidance  algorithms  for  inverse  dynamics  in  the  virtual 
domain  (IDVD)  and  for  angles  only  navigation  (AON). 

NASA  Goddard 

Mr.  Thomas  Flatley,  Code  587,  is  the  Branch  Chief  for 
the  Science  Data  Processing  Branch.  Mr.  Flatley  and 
researchers  in  his  branch  are  interested  in  the 
development  of  image  processing  algorithms  for 
creating  stereo  vision  with  one  camera  and  ranging  with 
visual-only  methods.  Mr.  Matt  Strube  and  Mr.  John  van 
Eepoel,  with  the  NASA  Satellite  Servicing  Capabilities 
Office  (SSCO),  have  confirmed  their  interest  in  using 
ARAPAIMA  as  a  platform  to  gather  relevant  on-orbit 
data  to  benefit  future  rendezvous  and  proximity 
operations  (RPO)  missions  such  as  the  geostationary 
Earth  orbit  (GEO)  based  satellite  servicing  concept 
currently  being  developed  by  SSCO. 

Collaboration  with  the  SCReAM  Lab 

The  Guidance  Navigation  and  Control  Group  in  the 
Spacecraft  Component  Technology  Branch  within  the 
Space  Vehicles  Directorate  of  the  Air  Force  Research 
Laboratory  located  at  Kirtland  Air  Force  Base  in  New 
Mexico  administers  the  SCReAM  Laboratory,  which  is 
involved  with  research  in  the  areas  of  relative  motion, 
image  processing  and  computer  vision,  all  of  which  fall 
squarely  within  the  core  science  mission  of 
ARAPAIMA.  Collaboration  would  benefit  both 
ARAPAIMA  mission  readiness  as  well  as  advance  the 
existing  research  within  AFRL/RV. 
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Two  phases  are  proposed  for  collaboration  with  the 
SCReAM  lab.  The  first  is  algorithm  development,  the 
second  is  Payload-in-the-Loop  (PIL)  testing.  If  the  I\&T 
timeline  allows  for  hardware  completion  prior  to  the 
January  2015  Flight  Competition  Review  (FCR)  for 
ARAPAIMA,  the  team  would  like  to  perform 
Hardware-in-the-Loop  (HIL)  testing  in  the  SCReAM 
lab  as  well. 

The  primary  point  of  contact  for  pre-algorithm 
development  on  ARAPAIMA  would  be  Dr.  Brien 
Flewelling,  Research  Aerospace  Engineer  with 
AFRL/RV  and  Director  of  the  SCReAM  lab.  Pre¬ 
existing  research  by  the  author  has  set  up  initial 
proximity  operations  simulations  for  relative  motion,  as 
well  as  camera  simulations  of  imaging  with  a  Narrow 
Field  of  View  (NFOV)  camera.  From  initial 
discussions,  several  areas  have  been  determined  for 
collaboration  and  advancement  of  existing  work. 

The  SCReAM  lab  has  a  full  simulated  star  tracker 
catalog.  Currently,  all  camera  simulations  involving  the 
RSO  (ARAPAIMA’s  upper  stage)  involve  a  dark 
background.  Generating  realistic  star  imagery  and 
testing  imaging  algorithms  will  help  with  accurate 
simulations  of  initial  RSO  acquisition,  Earth/Sun/Moon 
lighting/imagery  constraints,  etc. 

The  SCReAM  lab  is  involved  in  relative -motion  based 
computer  vision  problems,  several  of  which  will  be 
encountered  by  the  ARAPAIMA  mission.  Combining 
resources,  with  the  understanding  that  code  developed 
in  the  lab  will  remain  part  of  the  lab’s  repository,  will 
allow  for  furthering  the  understanding  of  future 
students  who  collaborate  with  the  lab. 

Autonomous  visual-only  imaging  and  pose  estimation 
will  involve  advanced  feature  detection  and  blending 
algorithms.  In  addition,  the  final  phase  of  ARAPAIMA 
will  select  a  “feature  of  interest”,  and  determine  the 
ability  of  the  cubesat  to  maintain  a  relative  orbit  in 
reference  to  that  feature  for  advanced  study. 
Reflectance  as  a  function  of  observer  angle  is  another 
area  that  has  not  been  studied  yet  for  ARAPAIMA. 

Currently,  all  images  that  are  tested  are  created  within 
the  MATLAB  simulation  environment.  Realistic 
images  will  help  determine  the  actual  performance  of 
the  flight  camera,  and  prepare  for  full  mission 
operations. 

After  the  Preliminary  Design  Review,  the  team  intends 
to  make  use  of  the  SCReAM  lab’s  Attitude  Control 
System  Proving  Ground  (ACS-PG)  to  perform  payload- 
in-the-loop  tests.  Models  of  various  representative 
RSOs  will  be  created  and  mounted  on  the  ACS-PG.  The 
goal  is  for  the  ARAPAIMA  payload  of  an  IR  camera 


and  a  Laser  Rangefinder  (LRF)  representative,  such  as 
the  X-Box  Kinect,  to  be  mounted  in  proximity  to  the 
ACS-PG. 

Imaging  algorithms  will  then  be  rigorously  tested  on  a 
variety  of  relative  motion  scenarios,  both  in-plane  and 
out-of-plane.  The  fidelity  of  the  algorithms  will  be 
tested,  and  improvements  suggested  for  operational  use 
as  applicable.  As  mentioned  previously,  if  sufficient 
hardware  integration  has  occurred  by  FCR,  the  team 
intends  to  use  the  Engineering  Development  Unit 
(EDU)  of  ARAPAIMA  to  the  ACS-PG  and  further  test 
the  capabilities  of  the  cubesat  to  perform  its  primary 
mission. 

The  primary  user  of  the  SCReAM  lab  would  be  Lt. 
Michael  (Mikey)  Nayak,  who  by  virtue  of  being 
assigned  to  Kirtland  Air  Force  Base,  already  has  access 
to  AFRL/RV  facilities.  The  next  step  would  be  lab 
access  for  Lt.  Nayak,  to  begin  collaborative  work  on 
algorithm  development.  It  is  anticipated  that  other 
ARAPAIMA  personnel  do  not  require  access  to  the 
SCReAM  lab  at  this  time. 

However,  during  PIL  testing,  it  is  possible  that  certain 
ERAU  students  may  wish  to  visit  the  lab,  both  to 
collaborate  on  the  testing  and  to  gain  outreach  with 
AFRL/RV.  This  is  in  line  with  the  objectives  of  the 
University  Nanosatellite  Program  (UNP)  as  well. 
Arrangements  for  these  students  will  be  made  on  a 
case-by-case  basis  through  the  proper  channels  in 
AFRL/RV. 

SPACECRAFT  OVERVIEW 
Military  Relevance 

The  primary  ARAPAIMA  mission  objectives  aim  to 
explore  and  directly  contribute  to  a  broad  range  of  next- 
generation  U.S.  national  security  objectives,  including 
but  not  limited  to  space  servicing,  space  diagnostics, 
space  support  and  autonomous  space  operations.  The 
mission’s  low-cost,  agile  cubesat  platform  plans  to 
demonstrate  key  capabilities  directly  applicable  to 
military  interests,  specifically  in  the  areas  of  space 
superiority  and  space  situational  awareness,  such  as 
rendezvous  and  proximity  operations,  autonomous 
mission  planning,  integration  of  commercial  off  the 
shelf  (COTS)  parts  for  low-cost  test  and  flight,  as  well 
as  other  enabling  space  technologies. 

The  ARAPAIMA  mission  addresses  three  of  the  Air 
Force  15  prioritized  space  capabilities: 

1.  Space  Situational  Awareness  (#4):  The 
mission  is  designed  to  perform  space-based  3D 
imaging  of  unknown  RSOs,  thus  enabling  the 
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SSA  capability  to  catalogue  space  systems 
from  a  space-based  platform,  as  well  as  to 
track  space  debris. 

2.  Satellite  Operations  (#8):  The  concept  of 
operations  (CONOPS)  requires  a  combination 
of  autonomous  and  ground  control  operations 
to  provide  highly  accurate  maneuvering 
solutions  for  formation  flying  with  the  RSO, 
thus  ARAPAIMA  addresses  the  satellite 
operations  capability. 

3.  Offensive  Space  Control  (#10):  The  mission 
also  enhances  offensive  space  control 
capability  through  the  novel  imaging 
algorithms  being  developed.  When  combined 
with  maneuvering  and  near-optimal  path 
planning  algorithms,  this  allows  the  maximum 
utilization  of  an  agile  micro  satellite  to  negate 
an  adversary’s  space  capabilities. 

Cubesat  integration:  The  military  utility  of  the 
ARAPAIMA  mission  can  be  derived  from  missions 
with  similar  objectives,  such  as  XSS-102,  XSS-113 
(AFRL)  and  Orbital  Express  4  (DARPA).  In  addition, 
the  cubesat  bus  can  be  directly  adapted  to  a  variety  of 
Department  of  Defense  (DoD)  science  and  engineering 
missions.  The  modular  design  leads  to  easy  payload 
integration,  for  example,  for  space  weather  missions  of 
interest  to  DoD  and  NASA,  low-cost  GPS, 
MILSATCOM,  and  DSP  gap-fillers. 

Long-term  impacts  to  military  missions  include  a 
continued  reduction  in  satellite  size,  a  decrease  in 
launch  costs  due  to  the  added  capability  for  lesser  mass, 
and  an  extension  of  the  capabilities  of  future  space 
missions. 

Orbital  debris  removal  and  asteroid  exploration:  The 
technologies  being  developed,  integrated,  and  tested  on 
ARAPAIMA  are  also  directly  applicable  to  the  field  of 
orbital  debris  removal.  ARAPAIMA  3D  imaging  and 
state  estimation  algorithms  can  be  employed  in 
collusion  with  algorithms  already  developed  by  other 
researchers  to  plan  the  maneuvers  for  imaging  and 
autonomous  docking  with  a  tumbling  asteroid.  Laser 
range  finder  algorithms  developed  for  ARAPAIMA  are 
applicable  to  measuring  surface  characteristics  and 
topography  mapping  for  small  satellite  asteroid 
missions.  Other  applications  of  ARAPAIMA 
technology  include  the  SeeMe  project  (DARPA). 

Lessons  learned  from  low-cost,  low-risk  integration  and 
test  will  be  documented  and  transferred  to  the 
operational  community,  such  as  AFSPC/A3,  to 
facilitate  development  of  future  CONOPS,  missions 
and  systems. 


Active  Orbital  Debris  Removal  in  Low  Earth  Orbit 

Orbital  debris  designates  all  of  the  man-made  objects  in 
Earth  orbit  which  no  longer  serve  a  useful  purpose,  e.g., 
inactive  spacecraft,  upper  stages  of  launch  vehicles, 
material  released  intentionally  or  unintentionally  during 
stage  separation,  and  material  resulting  from  upper 
stage  or  satellite  explosions  and  collisions.  Orbital 
debris  is  found  in  orbits  ranging  from  low  Earth  orbits 
(LEO)  to  geostationary  Earth  orbits  (GEO).  The  range 
with  the  largest  density  of  debris  spans  the  LEOs  from 
about  500km  to  1000km  altitude.  Recent  events,  such 
as  the  Chinese  antisatellite  test  of  1 1  January  2007  and 
the  collision  between  the  active  Iridium  33  (US) 
satellite  and  the  decommissioned  Cosmos  2251  (FSU) 
on  10  February  2009,  have  increased  the  total  number 
of  objects,  including  active  satellites  and  debris,  by 
125%  within  the  500-1000km  altitude  band.  The  danger 
that  orbital  debris  poses  to  active  satellites  and  the  crew 
of  the  International  Space  Station  (ISS)  is  obvious,  as 
demonstrated  by  the  collision  of  2009  and  by  the  fact 
that  within  a  year,  from  April  2011  to  March  2012,  the 
ISS  crew  and  operators  had  to  deal  with  six  orbital 
debris  events,  four  which  resulted  in  ISS  performing 
collision  avoidance  maneuvers  and  two  which  resulted 
in  the  crew  retreating  to  the  Soyuz  capsules  due  to  the 
lack  of  time  to  perform  collision  avoidance  maneuvers. 

To  address  the  increasing  danger  posed  by  orbital 
debris  two  types  of  measures  are  already  implemented 
or  are  planned  for  implementation  1)  mitigation  and  2) 
remediation.  Mitigation  of  orbital  debris  consists  of 
procedures  to  safely  re-enter  a  LEO  satellite  or  upper 
stage  within  25  years  at  the  end  of  mission,  aka  the  25- 
year  rule,  or  to  move  GEO  satellites  in  “graveyard” 
orbits.  According  to  Liou,  mediation  activities  on  LEO 
satellites  and  upper  stages  have  been  90%  successful  so 
far.1  Remediation  of  orbital  debris  consists  of  active 
debris  removal  (ADR)  and  to  this  date  no  ADR  mission 
has  been  flown.  In  the  same  study,  Liou  shows  that,  in 
the  assumption  that  the  mitigation  success  rate  is  kept  at 
90%  and  ADR  missions  commence  in  2020,  at  the  rate 
of  removing  five  large  objects  per  year,  the  total 
number  of  objects  in  LEO  would  increase  only  slightly, 
from  13,000  in  2010  to  14,000  in  2210.  The  “business- 
as-usual”  scenario  presented  by  Liou,  in  which  no  ADR 
missions  are  performed  and  the  mitigation  rate  is  the 
same  90%,  shows  that  the  total  number  of  objects  in 
LEO  almost  doubles  by  2210  reaching  22,000. 1 

The  imaging  and  attitude  state  estimation  and  relative 
navigation  algorithms  developed  and  tested  for  the 
ARAPAIMA  mission  will  be  combined  with  algorithms 
developed  by  other  researchers  to  plan  maneuvers  for 
the  capture  of  a  large  space  debris  object  such  as  a 
tumbling  upper  stage.  It  is  envisioned  that  multiple 
cubesats  similar  to  ARAPAIMA  are  launched  by  a 
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mother  ship,  they  attach  to  the  debris  object,  and 
together  they  gain  control  of  the  attitude  of  its  attitude. 
In  the  next  step,  the  cubesats  perform  deorbit  burns  and 
place  the  debris  object  in  an  orbit  with  a  perigee 
sufficiently  low  to  re-enter  in  a  given  number  of  years. 
The  cubesats  can  ride  along  on  the  debris  object  to  meet 
a  fiery  demise  or  they  can  return  to  the  mother  ship  for 
refueling  and  maneuver  to  the  next  debris  object  of 
interest. 

REQUIREMENTS 

There  are  many  different  requirements  from  multiple 
sources  that  need  to  be  followed  during  the  design 
process  of  the  satellite.  The  system’s  engineering  team 
has  compiled  these  requirements  into  a  Requirements 
Verification  Matrix  (RVM).  This  is  a  flow  down  from 
the  mission  objectives  and  mission  statements,  down  to 
the  subsystem  requirements.  The  step-by-step  flow 
down  for  the  ARAPAIMA  mission  is  shown  in  Figure 
55.  The  requirements  are  derived  from  the  mission 
statement,  objectives,  and  science.  Their  impact  on  the 
entire  space  system  is  traced  through  the  flow  down 
structure.  The  subsystem  leads  have  identified  their 
individual  functional  requirements,  in  order  to 
accomplish  the  mission.  Within  all  facets  of  the 
mission,  we  must  conform  to  UNP  programmatic 
constraint  requirements,  as  defined  in  the  UNP-8  User's 
Guide. 

Flowdown  Level  . 
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Figure  5:  Mission  Requirements  Flow  down 

This  matrix  contains  each  requirement  compiled  from 
UNP,  government  requirements,  and  requirements 
determined  by  the  team.  The  majority  of  the 
requirements  are  derived  from  the  different  UNP 
sources  (UNP-8  Users  Guide,  UNP  Expert  Area 
Teleconferences,  and  other  UNP  documentation). 

Each  requirement  consists  of  the  text  of  the 
requirement,  a  reference  ID,  the  method  of  verification, 
the  flow  down,  and  the  justification  for  each 
requirement.  The  reference  ID’s  are  used  to  easily  refer 
to  different  requirements  as  well  as  making  the  flow 
down  easier  to  follow.  There  are  three  verification 
methods  approved  for  the  UNP-8  competition;  testing, 
inspection,  and  analysis.  These  methods  will  describe 
how  each  requirement  will  be  verified.  Along  with 
these  methods  of  verification  is  a  check  mark  in  either  a 
red,  yellow,  or  green  section.  In  the  current  stage  of  the 
design  process,  the  check  signifies  what  stage  we  are  at 


in  the  verification  process.  Red  signifies  the 
requirement  is  not  verified,  yellow  signifies  that  some 
verification  had  begun,  and  green  signifies  that  the 
requirement  has  been  fully  verified.  The  flow  down 
shows  the  link  from  the  mission  objectives  to  the 
subsystem  requirements.  Finally,  each  requirement  has 
a  justification  alongside  it,  stating  why  the  requirement 
is  important  to  include  in  our  list.  Figure  6  is  a  copy  of 
the  payload  requirements  from  the  RVM  and 
demonstrates  the  general  set-up  of  ARAPAIMA's 
requirements. 


Figure  6:  ARAPAIMA  payload  requirements 
Risk  Analysis 

ARAPAIMA’s  system’s  engineering  team  has  also 
been  identifying,  analyzing  and  mitigating  mission 
risks.  To  determine  the  risks,  the  each  subsystem  has 
identified  situations  that  could  have  an  adverse  effect 
on  the  mission.  Once  these  situations  have  been 
identified  as  risks,  they  are  evaluated  and  managed  to 
ensure  prevention.  After  risks  are  defined,  the  team 
analyzes  and  prioritizes  each  risk  by  determining  the 
level  of  severity  of  the  risk.  The  team  is  currently 
working  on  assigning  numerical  values  to  traits  such  as 
probability,  impact  on  the  mission,  risk  control,  and 
effectiveness  of  control  based  off  of  the  information  in 
Figure  77. 


Risk  Exposure  Levels 


Risk  Factor  Rating  Meaning 

Probability 

10 

•  Risk  occurrence  is  imminent;  remote  chance  of  avoiding 
risk. 

5 

•  Risk  probability  is  moderate;  avoidance  is  probable 
with  consistent  planning. 

1 

•  Probability  that  risk  will  materialize  is  remote. 

Impact 

10 

•  Complete  compromise  of  project  objectives  leads  to 
project  failure  and  complete  loss  of  investment. 

5 

•  Risk  is  moderately  detrimental;  recoverable  with 
concerted  effort. 

1 

•  Risk  has  little  measurable  impact  to  project. 

Ability  to 
control 

10 

•  Risk  occurrence  is  completely  within  my  ability  to 
control. 

5 

•  I  have  moderate  ability  to  control  risk  occurrence  with 
regular  planning  and  mitigation  activities. 

1 

•  I  am  completely  unable  to  control  risk  or  influence 
avoidance  (i.e.,  natural  disaster,  geopolitical  instability). 

Effectiveness 
of  control 

10 

•  I  have  been  highly  effective  at  controlling  risk 
probability  and  impact. 

5 

•  I  have  been  moderately  effective  at  controlling  risk 
(definite  room  for  improvement). 

1 

•  I  have  been  completely  ineffective  at  controlling  this 
risk. 

Figure  7:  Risk  Exposure  Levels 


Harris 


8  27th  Annual  AIAA/USU 

Conference  on  Small  Satellites 


The  following  is  an  example  of  one  of  the  potential 
risks  from  the  payload  subsystem  concerning  the  laser 
rangefinder. 

•  Laser  Rangefinder:  In  general,  the  risk 
associated  with  the  laser  rangefinder  is  a  result 
of  it  not  functioning  properly.  Since  it  has  not, 
as  of  yet,  been  proven  to  operate  in  a  satellite, 
the  failure  of  this  component  is  of  concern. 
The  major  role  of  the  laser  rangefinder 
throughout  the  mission  is  to  provide  the  point 
clouds  required  to  image  the  satellite.  The 
consequence  of  the  laser  rangefinder  failing  to 
operate  is  analyzed  below  in  terms  of  the  risk 
management  process. 

•  The  laser  rangefinder  fails  to  operate: 

o  Severity:  Critical  (4) 
o  Deciding  risk  criterion:  Science  - 
Critical  reduction  of  the  science 
return 

o  Rationale:  Without  the  laser 

rangefinder,  the  monochrome  and 

infrared  cameras  will  still  be  able  to 
take  photos  of  the  RSO;  however,  the 
exact  attitude  determination  of  the 
RSO  will  not  be  able  to  be 

determined. 

o  Risk  treatment  plan:  i)  Flight  test  the 
laser  rangefinder  through  the  use  of 
the  a  weather  balloon  or  similar 
testing. 

o  Risk  Factor: 

■  Probability:  5 

■  Impact:  7 

■  Ability  to  control:  6 

■  Effectiveness  of  Control:  6 

After  these  numbers  are  defined,  they  will  be  used  to 
calculate  a  risk  factor  for  each  risk.  The  team  collected 
the  numerical  values  from  each  subsystem  and  each 
potential  risk  was  calculated  using  the  equation  shown 
in  Equation  1  . 

where  I  =  impact,  P  =  probability,  E  =  effectiveness, 
and  c  =  control. 

The  higher  the  risk  factor,  the  more  important  it  is  to 
mitigate  and  mange  that  risk.  ARAPAIMA  is  also  in  the 
process  of  determining  risk  mitigation.  The  system’s 
engineering  team  conducts  regular  risk  assessments  due 
to  the  continuous  evolution  of  our  system.  Figure  88 
contains  the  most  recent  risk  assessment  the  system’s 
engineering  team  has  completed.  After  each 


assessment,  the  system’s  engineering  team  looks  at  the 
risks  with  the  largest  risk  factor  and  determines  how  to 
manage  and  mitigate  the  risk.  Risks  that  have  a  low 
ability  to  control,  or  a  low  effectiveness  of  control,  are 
more  difficult  to  manage,  so  it  us  up  to  the  team  to 
determine  which  risks  are  able  to  be  managed. 


Tide 

Severity 

Impact 

Probability 

Control 

Effectiveness 
of  Control 

Risk 

Factor 

Power 

Space  debris  damage  solar 
cells 

8 

8 

1 

1 

63.36 

- 

Inoperable  communications 
system  because  of  OBC 
interface  software  failure  on 
spacecraft 

6 

8 

1 

S 

m 

Structures 

Space  debris  damaging 
structural  frame  and/or 
solar  panels 

Major  (3) 

5 

8 

1 

1 

39.6 

Cpmms 

Inoperable  communications 
system  because  of  damaged 
feeds  on  spacecraft. 

10 

9 

7 

8 

39.6 

Payload 

Monochrome  camera  fails  to 
operate 

Major  (3) 

10 

5 

6 

6 

32 

Power 

Bade  lies  experiences 
overcharging  or  overheating 

mil 

9 

5 

5 

6 

Power 

The  batteries  experience 
high  currents 

Major  (3) 

8 

5 

5 

5 

[m 

Payload 

IR  Camera  fails  to  operate 

Significant 

(2) 

9 

S 

6 

6 

28.8 

■ - 

Significant 
(2)  to  Critical 

6 

S 

6 

2 

Figure  8:  ARAPAIMA  Risk  Assessment  Table 
PRIORITIZATION  PLAN 

Spacecraft 

The  subsystems  of  the  ARAPAIMA  mission  have  been 
characterized  according  to  their  impact  on  the  mission 
and  according  to  their  complexity.  They  are  presented 
in  Figure  99.  The  impact  is  a  weighted  sum  of  the 
impact  on  the  cost,  budget,  schedule,  and  technical 
performance.  The  complexity  is  defined  in  the  sense  of 
information  content,  as  suggested  by  Suh.  As  such,  a 
complex  subsystem  is  one  for  which  the  information 
content  required  to  satisfy  its  functional  requirements  is 
high. 

Subsystems  in  the  top  right  quadrant  are  the  most 
critical  ones  and,  accordingly,  their  functionality  is 
considered  highly  critical.  They  are  followed  in  terms 
of  criticality  by  the  systems  in  top  left  quadrant,  which 
have  been  considered  to  provide  critical  functionality. 
The  subsystems  with  medium  critical  functionality 
reside  in  the  lower  right  quadrant. 
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Critical 

functionality 

High 

Impact 

High  critical 
functionality 

Payload 

\  Power 

Com  ms 

*  ^ 

Propulsion  OBC 

?► 

ADCS 

Low 

High 

Complexity 

Structures 

Complexity 

Low  critical 
functionality 

Thermal 

Medium  critical 
functionality 

Low 

Impact 

Figure  9:  Subsystem  Characterization 

For  the  time  being  both  the  impact  on  the  mission  and 
the  complexity  of  the  subsystems  are  chosen 
heuristically,  according  to  the  team’s  experience  and 
intuition.  Both  the  impact  and  complexity  have  been 
further  quantified  in  the  Risk  Analysis  section.  In 
addition,  the  results  or  expectations  of  risk  mitigation 
measures  that  are  proposed  will  also  be  quantified  and 
presented  in  similar  quadrant-chart  to  illustrate  the 
progress  of  the  design  and  how  the  design  decisions 
mitigate  the  risk.  After  the  PDR  the  same  approach  will 
be  followed  to  keep  track  of  the  risk  and  criticality 
during  the  manufacturing  and  partial  integration  stages. 

Payload  Descope  Plan 

The  payload  descope  plan  presented  here  describes  an 
initial  attempt  at  specifying  descope  options.  It  will  be 
revisited  and  updated,  if  needed,  in  the  month  after  the 
SCR  to  quantify  the  impact  on  the  mission  performance 
and  mission  requirements. 

The  first  payload  component  descope  option  is  the 
reduction  of  the  resolution  of  the  visible  spectrum 
monochrome  camera.  The  rationale  is  the  reduction  of 
cost,  power  required,  and  image  size.  The  impact  is  a 
reduction  of  the  data  that  has  to  be  stored  for  processing 
and  possible  downlink. 

The  second  payload  component  descope  option  is  the 
elimination  of  the  payload  computer  and  using  the  bus 
computer  to  run  the  payload  science  algorithms.  The 
rationale  is  the  reduction  of  cost,  power  and  volume 
required.  The  impact  is  a  reduction  in  the  CPU  cycles 
allocated  to  payload  science  algorithms  and  a  reduction 
of  the  reliability  of  the  overall  OBC  architecture. 


The  third  payload  component  descope  option  is  the 
elimination  of  the  IR  spectrum  camera.  The  rationale  is 
the  reduction  in  cost,  power  and  volume  required.  The 
impact  is  a  reduction  in  the  science  to  be  performed, 
increase  the  risk  to  the  mission  due  to  the  inability  to 
observe  the  RSO  during  the  eclipse  side  of  the  orbit. 
Imaging  of  the  laser  bloom  on  the  RSO  is  also 
eliminated.  However,  the  imaging  of  the  laser  bloom 
might  be  performed  by  the  visible  spectrum  camera. 

Spacecraft  Bus  Descope  Plan 

It  is  important  to  note  that  two  ADCS  descope  options 
have  already  been  exercised.  They  consist  of  the 
elimination  of  one  of  the  two  star-trackers  and  one  of 
the  four  reaction  wheels.  The  rationale  is  the  reduction 
of  cost,  power,  and  internal  volume  requirements.  The 
impact  is  a  reduction  of  the  reliability  of  the  ADCS. 

Prioritization  of  tasks:  Science  &  Mission  Imaging 

Figure  2  shows  the  expected  science  Concept  of 
Operations  (CONOPS)  for  ARAPAIMA.  Each  box 
shown  below  is  being  developed  as  research  code  in 
MATLAB.  It  will  then  implemented  in  ANSI  C  for 
flight  software  and  tested  as  part  of  an  end-to-end 
payload-in-the-loop  simulator,  likely  at  the  Sensor- 
based  Control  for  Relative  Motion  (SCReAM) 
laboratory  at  AFRL’s  Kirtland  AFB  location. 

Figure  1010  shows  the  expected  descope  plan  for 
science  and  mission  imaging,  should  the  full 
development,  verification  and  testing  of  all  the  research 
code  required  for  the  tasks  shown  in  Figure  23  be 
infeasible. 


Figure  10:  Descoped  ARAPAIMA  Science  Conops 

The  first  step  of  the  descope  plan  would  involve  cutting 
development  of  secondary  objective  research  to  fulfill 
primary  objectives,  such  as  waypoint  guidance 
development  (and  associated  autonomous  programming 
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conditions).  Secondary  objectives  are  still  in 
development  as  part  of  the  ARAPAIMA  Experiment 
Plan,  which  will  be  completed  by  the  Chief  Scientist, 
Lt.  Nayak,  by  Preliminary  Design  Review  (PDR).  It  is 
expected  that  more  secondary  objectives  will  be  added 
with  additional  collaborators  /  customers. 

The  second  step  of  the  descope  plan  would  involve 
cutting  development  related  to  the  objective  of  proving 
the  capability  to  dock  with  a  non-cooperative  RSO.  It  is 
not  expected  that  docking  will  occur,  however,  the 
science  team  would  like  to  evaluate  the  pointing, 
guidance  and  navigation  of  the  satellite  with  respect  to 
a  particular  feature  of  interest  on  the  RSO  and 
implement  a  closed-loop  error  model  to  compensate  for 
perturbations  and  other  errors.  This  will  allow  for  an 
evaluation  of  ARAPAIMA’ s  ability  to  deliver  products 
based  on  these  highly  demanding  conditions. 
Researching,  coding  and  testing  the  execution  and 
evaluation  of  this  final  condition  is  expected  to  be 
highly  time-intensive,  and  preference  will  be  given  to 
primary  objectives  if  the  timeline  to  flight  software  load 
does  not  permit  a  satisfactorily  mature  development.  It 
is  expected  that  all  other  science  objectives  shown  as 
outside  the  descope  cloud  in  Figure  10  can  be 
completed  by  a  January  2015  Flight  Competition 
Review  (FCR)  timeline. 

INTERNAL  ORGANIZATION 

GIT  for  Version  Control 

Currently,  the  science  team  has  eleven  members,  all  of 
whom  are  involved  in  various  aspects  of  coding 
research  code  to  execute  various  ARAPAIMA 
objectives.  While  documentation  of  this  code  can  be 
daunting,  during  the  development  phase,  version 
control  of  improved  versions  can  be  even  more  so. 
Common  subfunctions,  such  as  calculations  of 
ephemeris,  ingest  of  TLE,  ingest  of  images,  solar  phase 
angle  modeling,  etc,  are  used  by  multiple  participants, 
and  modifications,  if  not  tracked,  could  lead  to  a  failure 
to  compile  all  this  work  into  one  end-to-end  mission 
simulator,  and  ultimately,  into  flight  software. 

Git  is  a  free  and  open  source  distributed  version  control 
system  designed  to  handle  everything  from  small  to 
very  large  projects  with  speed  and  efficiency.  Git 
allows  multiple  local  branches  that  can  be  entirely 
independent  of  each  other.  This  allows  the  science  team 
to  perform  the  following: 

•  Context  Switching.  Create  a  branch  to  try  out 
an  idea,  switch  back  to  the  original  branch, 
apply  a  working  patch,  switch  back  to  the 
experimentation  branch,  and  merge  it  in. 


•  Role-Based  Codelines.  Have  a  branch  that 
always  contains  only  what  goes  to  production, 
another  that  work  for  testing  is  merged  into, 
and  several  smaller  ones  for  day  to  day  work. 
These  have  all  been  implemented  in  the 
ARAPAIMA  Git. 

•  Feature  Based  Workflow.  Members  can  create 
new  branches  for  each  new  feature  so  the 
overall  team  can  seamlessly  switch  back  and 
forth  between  them,  then  delete  each  branch 
when  that  feature  gets  merged  into  the  main 
(‘production’)  line. 

•  Disposable  Experimentation.  Create  a  branch 
to  experiment  in,  realize  it's  not  going  to  work, 
and  just  delete  it  -  abandoning  the  work  -  even 
if  other  branches  have  been  pushed  to  the 
repository  in  the  meantime).  This  frees 
members  to  try  new  ideas  without  worrying 
about  having  to  plan  how  and  when  they  are 
going  to  share  it  with  others. 

Overall  GIT  version  control  and  branch  control  rests 
with  the  Chief  Scientist,  to  allow  for  approval  of 
‘successful’  code  as  ready  for  on-board 
implementation.  This  is  proving  to  be  highly  successful 
even  with  introducing  new  members  to  the  team,  as 
they  can  be  allowed  access  to  a  particular  branch  of 
code,  without  disrupting  anyone  else’s  work,  or 
requiring  transfer  of  large  files  via  email. 

Conference  Plan 

Conferences,  both  national  and  international,  present  a 
stellar  opportunity  for  the  ARAPAIMA  team  to  present 
their  concepts  and  receive  peer-review  from  a 
community  involved  in  similar,  if  not  identical,  tasks. 
Publications,  both  in  conference  proceedings  and 
technical  journals,  are  a  large  part  of  the  science  team’s 
validation  of  new  ideas. 

Figure  1 1  shows  a  list  of  conferences  at  which  the  team 
will  be  presenting  ARAPAIMA-related  research  in 
2013,  for  a  likely  total  of  ten  published  papers. 


Figure  11:  List  of  conferences  ARAPAIMA  will  be 
presenting  in  2013 
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SVN for  Version  Control 

The  spacecraft  team  has  various  subsystems  that  require 
code  to  be  written  in  order  to  meet  ARAPAIMA 
objectives.  For  example,  the  attitude  determination  and 
control  subsystem  is  modeling  the  reaction  wheels 
using  Simulink;  while  on-board  computing  is 
generating  the  code  to  interface  with  the  laser  range 
finder.  As  various  file  types  are  being  generated  and 
iterated  it  is  important  to  have  a  versioning  system  in 
place.  SVN  is  our  versioning  system  of  choice  because 
it  is  directly  supported  by  MathWorks  and  their 
Simulink  Projects  environment. 

SVN  is  a  universally  recognized  and  adopted  open- 
source,  centralized  version  control  system  characterized 
by  its  reliability  as  a  safe  haven  for  valuable  data;  the 
simplicity  of  its  model  and  usage;  and  its  ability  to 
support  the  needs  of  a  wide  variety  of  users  and 
projects.  Some  of  the  key  features  of  SVN  that  will  be 
utilized  by  the  spacecraft  group  are: 

•  Ticketing  Tools.  Create  a  work  ticket  for  a 
certain  file  stating  what  it  is  that  needs  to  be 
fixed.  When  the  issue  is  resolved  the  ticket  is 
filed  away  under  completed  tasks. 

•  Branches.  Using  side-line  development  will 
facilitate  the  creation  of  experimental  work 
that  could  be  disruptive  to  the  trunk  until  it  is 
properly  tested.  Branches  also  allow  for  the 
development  of  multiple  versions  of  the  same 
product  for  later  evaluation  and  testing. 

•  Visual  Cues.  Using  tags  to  highlight  notable 
revisions  in  the  history  of  the  repository  will 
allow  for  easier  navigation  and  readability  of 
the  code  base. 

•  Multiple  Repositories.  Various  subsystems  of 
the  spacecraft  may  need  to  develop  software 
that  will  be  iterated  over  the  lifetime  of  the 
project.  By  allowing  each  subsystem  to  have  a 
repository  the  code  base  will  not  be 
overbearing. 

Version  control  of  the  trunk  (main  branch)  of 
development  will  be  in  control  of  each  subsystem  lead. 
Experimental  branches  can  be  used  by  anyone  looking 
to  further  develop  the  software  without  worrying  about 
breaking  the  trunk.  Once  experimental  code  becomes 
mature  enough  the  subsystem  lead  will  have  the  ability 
to  merge  the  branches. 

Assigning  Tasks 

Ensuring  that  tasks  are  assigned  to  the  proper  groups  as 
quickly  and  efficiently  as  possible  helps  to  keep  the 
project  moving  forward  in  a  unified  direction.  The  web 
service  Evernote  is  a  critical  part  of  issuing  and 


prioritizing  tasks.  Each  of  the  ARAPAIMA  subsystems 
has  a  premium  Evernote  account  that  allows  the  sharing 
of  notebooks.  The  “ARAPAIMA  Program 
Management”  notebook  contains  a  to-do  list  note  for 
each  subsystem.  The  program  manager,  systems 
engineers,  and  subsystem  team  leads  add  tasks  to  the  to- 
do  lists.  The  standard  format  for  writing  to-dos  denotes 
the  importance  level  (critical,  uncritical),  priority 
(urgent,  not  urgent)  and  the  due  date  for  each  task. 
Once  a  task  is  completed  the  to-do  is  checked  off  and  a 
line  is  added  indicating  the  person  who  completed  the 
task. 

In  order  to  ensure  that  tasks  are  being  placed  in  their 
proper  locations,  and  with  the  correct  importance  and 
priority  levels,  the  project  manager,  systems  engineers, 
and  principle  investigators  share  a  notebook  where 
ideas  can  quickly  be  added  and  don’t  require  the  same 
structure  as  the  program  management  notebook. 
Additionally,  every  week  there  is  a  subsystem  team 
lead  meeting  including  the  project  manager  to  discuss 
tasks  completed  the  previous  week,  and  to  assign  new 
tasks  for  the  upcoming  one. 

File  Naming  Convention 

A  standardized  file  naming  convention  is  an  efficient 
and  practical  method  of  maintaining  documents,  files, 
and  folders.  The  web  service  Dropbox  is  the  main 
method  for  saving  any  and  all  pertinent  files.  Every 
member  participating  in  the  ARAPAIMA  project  has 
access  to  the  shared  ARAPAIMA  folder  within  the 
Dropbox  web  service.  The  file  naming  convention  is 
outlined  below. 

•  (Subsytem  abbreviation) (Three  digit  code)- 
(Descriptive  Title) 

•  E.G.  “SUB  1 00-Example” 

•  All  spaces  between  words  are  denoted  by  an 
underscore  to  ease  use  on  Linux-based 
computers 

•  All  documents  (Word  and  Excel)  have  a  table 
of  revisions  with  the  following  fields: 

o  Revision  number 
o  Description  of  changes  made 
o  Date  of  the  change 

o  Initials  of  approval  from  superior 

This  system  was  inspired  by  ARMADILLO  (The 
University  of  Texas  at  Austin) 

The  file  naming  convention  is  outlined  further  in  Figure 
12.  Here  it  shows  the  breakdown  of  what  type  of 
documents  to  expect  for  each  three-digit  code. 
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INTERNAL  REVIEWS 


Subsystem 


Figure  12:  The  documentation  plan  structure  for  file 
naming 

In  the  three-digit  code  for  the  naming  convention,  the 
second  and  third  numbers  are  determined  by  the 
spacecraft  component  that  the  document  is  referring  to. 


spacecraft  Component  Identification  Numbers 


Figure  13:  Spacecraft  component  identification 
numbers 

The  numbering  convention  is  called  the  spacecraft 
component  identification  number.  This  list  of  numbers 
is  developed  along  with  the  spacecraft  as  more 
components  are  researched  and  added  to  the  design.  An 
example  of  the  numbering  convention  for  some  of  the 
components  used  in  ARAPAIMA  are  shown  in  Figure 
133. 


Spacecraft 

The  team  is  actively  recruiting  members  of  for  its 
Advisory  Board  from  the  space  industry  and 
government  organizations  that  conduct  space  related 
research  and  development.  Experts  are  sought  from  all 
branches  of  space  mission  design.  Once  the  Advisory 
Board  is  mobilized  its  members  will  be  asked  to  advise 
in  the  design  of  the  spacecraft  subsystems  and  review 
design  decisions  taken  by  the  team.  The  members  of  the 
Advisory  Board  will  be  provided  with  draft  review 
presentations  and  review  reports  in  a  timely  manner  to 
allow  for  feedback  prior  to  release  of  the  documents  to 
the  UNP  PO. 

In  addition  to  the  experts  of  Advisory  Board,  which  are 
all  external  to  the  both  ERAU  and  U  of  Ark,  the  team 
will  engage  with  faculty  at  the  respective  campuses 
with  either  advising  students  or  direct  contributions  to 
the  ARAPAIMA  research  and  development  effort.  At 
ERAU  Prof.  Hamilton  Hagar  is  currently  engaged  in 
advising  the  ARAPAIMA  System  Engineer  Lead  with 
the  derivation  and  traceability  of  the  requirements,  Prof. 
William  Barrot  is  advising  the  Communication 
Subsystem  Lead  with  the  radio  communication  system 
design  and  link  budget  analysis,  Prof.  Marc  Compere 
is  advising  the  Power  Subsystem  Lead  with  the 
development  of  the  requirements  and  preliminary 
power  budget  analysis,  and  last  but  not  least  Prof.  Peter 
Erdman  is  advising  the  Payload  Engineers  in  the 
design  and  specification  of  the  requirements  for  optical 
assemblies  and  IR  camera. 

The  ARAPAIMA  mission  has  intimately  linked  with 
the  Spacecraft  Design  courses  (AE427/AE445)  at  the 
ERAU  Aerospace  Engineering  Department  during  the 
2012-13  academic  year.  The  current  team  is  transferring 
the  leadership  and  technical  expertise  to  a  set  of 
volunteers  whom  will  work  outside  of  the  design 
classes.  It  is  expected  that  during  the  2013-14  the 
ARAPAIMA  project  will  be  decoupled  from  the 
Spacecraft  Design  courses  but  top  performing  students 
will  be  recruited  for  ARAPAIMA  work. 

An  additional  form  of  peer  and  community  review  of 
the  ARAPAIMA  work  is  pursued  by  attending 
conferences  and  possibly  publishing  papers  in  peer 
reviewed  journals.  The  conference  papers  either 
presented  or  in  progress  are  shown  in  Figure  14. 
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# 

Paper  Title 

Conference 

Date 

Status 

1 

Application  of  a  Laser  Rangefinder 
for  Space  Object  Imaging  and 
Shape  Reconstruction 

2013  AAS  Space  Right 
Dynamics  Conference 

Feb  10-14,2013 

Presented 

2 

Experimental  Characterization  of  a 
Miniature  Laser  Rangefinder 

2013  AAS  Space  Right 
Dynamics  Conference 

Feb  10-14, 2013 

Presented 

3 

Design  of  Relative  Motion  and 
Attitude  Profiles  for  Three- 
Dimensional  Resident  Space 
Object  Imaging  with  a  Laser 
Rangefinder 

2013  IEEE  Aerospace 
Conference 

Mar  2-9, 2013 

Presented 

4 

Real-Time  Attitude  Commanding  to 
Detect  Coverage  Gaps  and 
Generate  High  Resolution  Point 
Clouds  for  RSO  Shape 
Characterization  with  a  Laser 
Rangefinder 

2013  IEEE  Aerospace 
Conference 

Mar  2-9, 2013 

Presented 

5 

Mission  Design  and  Concept  of 

Operations  of  a  6U  CubeSat 
Mission  for  Proximity  Operations 
and  RSO  Imaging 

5"  Inti.  Conference  on 

Spacecraft  Formation  Flying 
Missions  and  Technologies 

May  29-31, 2013 

Presented 

6 

Application  for  RSO  Automated 
Proximity  Analysis  and  IMAqina 
(ARAPAIMA):  Development  of  a 
Cubesat-based  Space  Situational 
Awareness  Mission 

SmallSat  Conference  2013 

Aug  10-15, 2013 

Abstract 

accepted 

6 

Payload  and  AOCS  of  a  12U 
Cubesat  for  Asteroid  Scouting 

2013  AIAA  GNC  Conference 

Aug  19-22, 2013 

Abstract 

accepted 

Figure  14:  Conference  papers  related  to  the 
ARAPAIMA  mission 


Science 

Weekly  status  reviews  are  conducted  with  the  Chief 
Scientist,  Lt.  Nayak,  to  ensure  that  all  team  members 
are  staying  on  track  with  assigned  objectives.  A  high- 
level  Microsoft  Project  schedule  is  used  to  map 
research  objectives  to  flight  software  needs,  via  the 
high-level  CONOPS  diagram. 

Conference  peer  review  and  the  paper  submission 
process  present  an  excellent  opportunity  for  team 
members  to  exercise  research  rigor  and  method 
documentation.  As  seen  in  Section  9,  the  Science  team 
plans  to  use  the  conference  and  journal  process  as  an 
integral  part  of  the  creation  and  validation  of 
ARAPAIMA-ready  flight  software. 

PERSONNEL  BUDGET 

Responsibilities  of  student  team  and  subsystem  leads 

Each  subsystem  has  specific  responsibilities  that  will 
help  them  accomplish  their  goals.  The  power  subsystem 
is  required  to  create  the  power  budget,  define  battery 
and  solar  panel  specifications,  and  determine  the  power 
board  components  that  will  be  used.  Attitude, 
determination,  and  control  subsystem  will  be 
responsible  for  simulation  modeling,  writing  technical 
specifications,  and  defining  reference  frames.  The 
payload  subsystem  will  design  and  manufacture 
components,  test  the  payload,  and  validate  their  tests 
results.  The  communications  subsystem  will  define  a 
link  and  data  budget,  and  create  antenna,  radio,  and 
ground  station  specifications.  The  structures  subsystem 
will  provide  CATIA  designs,  structural  finite  element 
analysis,  and  rapid  prototyping.  The  thermal  subsystem 
will  perform  thermal  analysis  and  define  satellite 
safeguards.  The  OBC  subsystem  will  test  their 
components,  select  hardware  and  software  to  be  used, 
and  create  accurate  interfacing. 


Propulsion  Subsystem 

The  ARAPAIMA  propulsion  system  is  being  developed 
in-house  at  the  University  of  Arkansas’s  Mechanical 
Engineering  Department.  The  personnel  of  this 
subsystem  is  drawn  upon  mainly  from  the  members  of 
the  UA  American  Institute  of  Aeronautics  and 
Astronautics  (AIAA)  Student  Chapter  and  from  the 
students  interested  in  the  space  hardware  design  for 
their  ME  senior  capstone  (MEEG-4131,  -4133;  two 
semesters).  The  UA  ME  Department  currently  includes 
a  student  body  of  approximately  500  undergraduate 
students,  including  declared  freshmen  class  of  2012-13. 

The  UA  ARAIPAIMA  propulsion  team  is  expected  to 
consist  of  students  with  ranks  from  freshmen  to  senior. 
The  team  is  currently  recruiting  students,  starting  with 
senior  capstone  students  and  then  followed  by 
voluntary  students  of  lower  ranks.  The  Propulsion 
System  Lead  is  Zachary  Callahan.  Mr.  Callahan  is 
currently  a  3rd  year  senior-rank  student  completing  his 
core  ME  curriculum  (statics,  dynamics,  materials, 
mechanics  of  materials,  numerical  methods, 
thermodynamics,  fluid-mechanics,  heat-transfer, 
machine  analysis/design,  electronics,  and  ME  labs). 
Complementing  them  are  his  hands-on  extracurricular 
experiences  from  the  summer  Research  Experiences  for 
Undergraduates  (2012)  and  current  position  as  a  UA 
Honors  College  research  student,  providing  the 
technical  leadership  and  management  of  the 
ARAPAIMA  propulsion  system  team.  Ideally,  each 
subsystem  should  be  managed  by  students  (5  members) 
with  similar  curricular  experiences  as  Mr.  Callahan; 
however,  it  can  be  further  delegated  to  lowerclassmen 
such  as  freshmen  (CAD),  sophomore  (materials, 
analysis),  junior  (manufacturing). 

Identified  Gaps  in  Personnel/Expertise 

As  a  team  we  demonstrate  expertise  in  many  different 
software  packages  such  as  Microsoft  Office,  Visio, 
MATLAB,  CATIA  V5,  Systems  Tool  Kit  (STK), 
Nastran,  and  Simulink.  These  qualifications  were 
acquired  through  industry  experience,  class  projects, 
and  technical  club  involvement.  Team  members  are 
also  expected  to  be  able  to  think  critically  and  solve 
technical  challenges. 

SUBSYSTEM  PROGRESS 

Attitude  Determination  and  Control 

Since  inception,  the  ADC  team  has  been  working  hard 
researching  and  implementing  the  attitude  dynamics  of 
a  satellite  in  low  earth  orbit.  External  and  internal 
torques  have  been  derived  and  simulated  to  better  the 
accuracy  of  the  model.  Recently,  preliminary  controller 
design  to  satisfy  pointing  requirements  has  started.  The 
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pointing  requirements  include  and  knowledge  accuracy 
of  at  least  1  arcminute  during  the  science  mode  and  a 
control  accuracy  of  at  least  2  arcminutes  during  the 
science  mode. 

The  modeled  disturbance  torques  include  aerodynamic, 
gravity  gradient,  residual  magnetic  moment,  solar 
radiation  pressure,  reaction  wheel  imbalance,  propellant 
slosh,  solar  panel  vibration,  and  orbital  maneuver 
thruster  misalignment. 


Data  Link 

Margin  achieved 

9.03  dB 

Downlink 

Budget 

Carrier  to  Noise 
Ratio 

71.19  dB-Hz 

Data  Link 

Margin  achieved 

6.35dB 

Future  designing  and  testing  will  ensure  our  ADC 
algorithm  will  continue  to  deliver  the  required  attitude 
for  all  operational  modes  during  the  actual  mission. 

Communications 

The  radio  for  the  nanosat  has  been  selected  and  in  the 
process  of  being  purchased.  The  architecture  of  the 
communications  system  is  shown  in  Figure  155  with 
the  chosen  components  noted.  The  link  budget  is 
completed  and  has  identified  the  type  of  antennas 
needed  to  have  proper  communication  between  the 
ground  station  and  the  nanosat.  Testing  of  the 
placement  of  the  antennas  are  currently  in  progress. 


Electrical  Power  System 

The  power  subsystem  has  made  significant  progress 
since  the  beginning  of  the  project.  Early  on  the  satellite 
modes  were  established,  a  preliminary  STK  analysis  for 
power  acquisition  was  constructed,  and  a  preliminary 
power  budget  was  produced.  As  the  project  matured  so 
did  the  power  budget,  as  well  as  the  need  to  do 
preliminary  testing  of  the  power  consumption  of  the 
individual  subsystems.  The  block  diagram  for  the 
power  subsystem  describes  the  flow  from  the  solar 
panels  through  to  each  spacecraft  component  and  is 
shown  in  Figure  166. 


Figure  155:  Communications  architecture 

The  analysis  for  the  communications  system  using  the 
link  budget  resulted  in  the  values  shown  in  Table  1. 


Most  recently  we  have  constructed  breadboard  models 
emulating  the  components  of  their  respective  subsystem 
and  we  have  started  some  preliminary  testing  to  ensure 
the  power  subsystem  can  adequately  sustain  the  entire 
system. 


Table  1:  Communications  analysis  values 


Lrequencies 

Uplink 

450  MHz  (UHL) 

Downlink 

2.25  GHz  (S-band) 

Uplink 

Budget 

Carrier  to  Noise 
Ratio 

54.58  dB-Hz 

On-Board  Computer 

The  On-Board  Computing  (OBC)  team  has,  in  the 
course  of  the  project,  designed  both  the  main  computer 
and  payload  computer  for  the  ARAPAIMA  satellite  and 
an  interface  method  between  the  computer  and  the 
various  subsystems.  The  software  for  the  computers  is 
Real-time  Linux  OS  with  custom  JAVA  based  system 
control  software.  The  overall  software  architecture  can 
be  seen  in  Figure  177. 
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The  OBC  team  has  also  finished  construction  of  the 
payload  computer,  and  has  nearly  finished  the  creation 
of  the  payload  computer  software,  which  will  allow  a 
simple  interaction  between  ground  station  and  satellite. 
Testing  has  also  been  done  to  ensure  that  the  payload 
computer  can  handle  all  data  processing  and  command 
tasks  required  of  it. 


Figure  177:  ARAPAIMA  software  architecture 
Payload 

In  the  design  of  the  project,  the  payload  subsystem  has 
taken  many  steps  toward  designing,  integrating,  and 
testing  the  payload  components  for  the  nanosat.  Each  of 
the  components  for  the  payload  have  been  selected  and 
are  starting  to  be  purchased.  Testing  has  been 
completed  using  an  emulator  of  the  payload 
components,  this  testing  has  allowed  us  to  identify 
where  we  need  more  information  and  the  success  with 
which  the  components  work  together.  In  the  near  future, 
further  testing  will  be  completed  to  test  the  payload 
with  moving  targets  and  test  the  fidelity  of  the  written 
algorithms. 

The  results  of  testing  on  the  laser  rangefinder  allowed 
for  error  characterization  for  the  laser  rangefinder 
modeling  in  the  algorithms.  The  modeling  includes 
errors  caused  by  pulse  dilation  and  the  influence  of  the 
material  reflectance  on  the  readings.  One  of  the  many 
graphs  of  the  results  is  shown  in 
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Figure  188:  Laser  rangefinder  testing  results 


Propulsion 

Throughout  the  progress  of  the  project  the  propulsion 
subsystem  has  focused  on  three  areas:  propellant  tank 
design,  propellant  delivery  system  design,  and  the 


Harris 


16  27th  Annual  AIAA/USU 

Conference  on  Small  Satellites 


valve/nozzle  design.  At  this  point  they  have  a  working 
propellant  tank  design  which  serves  the  dual  purpose  of 
propellant  reservoir  and  structural  reinforcement  for  the 
satellite's  chassis.  The  propellant  delivery  system  is  less 
definite  since  it  depends  on  the  placement  of  other 
hardware  within  the  body,  but  a  generic  pipe  and 
connector  design  is  ready  and  awaiting  modifications. 
Finally,  the  valve  design  has  been  the  subsystem's  main 
focus;  it  consists  of  a  working  valve  driver  circuit 
design,  a  prototype  communication  or  logic  board,  and 
a  system  of  solenoid  valves.  The  design  makes  good 
use  of  the  satellite's  space  and  power  supply.  It  is  also 
flexible  enough  to  allow  for  different  valve  models  or 
propellants  to  be  tested  once  the  hardware  has  been 
assembled. 

The  current  specifications  for  the  propulsion  system 
include  using  HFC-236fa  with  an  Isp  of  47s  along  with  a 
500mN  orbital  maneuver  thruster,  and  8  lOmN  RCS 
thrusters.  The  propulsion  diagram  is  shown  in  Figure  19. 


Figure  19:  Propulsion  system  diagram 


Structures 

In  the  design  of  the  structure  there  were  many  issues  to 
consider.  To  begin,  there  was  no  heritage  design  to  go 
from,  so  we  decided  to  make  the  structure  as  simple  in 
robust  as  possible.  Therefore  we  made  the  baseplate 
thicker  than  the  rest  of  the  structure  it  would  take  the 
most  loading  and  also  incorporated  the  rails  that  are 
attached  to  the  CSD.  To  achieve  this  we  did  a  lot  of 
FEA  with  Femap/NeiNASTRAN  as  well  as  CATIA  V5 
to  simulate  the  loads  that  might  occur  during  flight.  We 
also  model  the  structure  in  CATIA  which  then  we  were 
able  to  rapid  prototype  it  using  our  3D  printer.  This 
allowed  us  to  make  sure  that  all  the  components  fit 
together  nicely. 


One  of  the  first  finite  element  analysis  (FEA)  that  we 
performed  was  400N  to  the  -Z  face  because  that  is  the 
force  which  is  imparted  by  the  CSD  ejection  plate 
during  launch  due  to  vibration.  As  seen  below  in 


Figure  20:  FEA  of  4QQN  applied  to  the  -Z  face 


Figure,  our  structure  had  a  displacement  of  2.498  mm 
shown  in  the  bottom  left  corner.  Our  next  FEA  was  to 
apply  the  max  amount  of  gravitational  forces  that  the 
cubesat  may  encounter  during  launch  in  the  Titan  IV. 
Based  on  the  Mass  Acceleration  Curve  (MAC)  of  Titan 
IV  and  the  maximum  mass  constraint,  12kg,  of  our  6U 
cubesat  we  approximated  that  it  would  undergo  20g’s 
of  force. 


Figure  20:  FEA  of  400N  applied  to  the  -Z  face 
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Figure  shows  2352N  or  20g’s  of  force  being  exerted  on 
the  top  plate  of  the  cubesat.  The  deformation  was 
calculated  to  be  71.94  mm,  this  is  a  big  deformation  for 
the  satellite  but  this  analysis  is  only  for  the  chassis.  The 
propellant  tank,  which  is  located  in  the  2  middle  units, 
and  trays,  containing  the  payload,  act  as  secondary 
supports  and  help  the  structure  maintain  its  integrity. 


Figure  21:  Top  plate  undergoing  2352N 

The  current  structure  and  components  can  be  seen  in  . 


Systems 

The  System’s  engineering  subsystem  of  the  team  has 
been  an  important  part  of  the  design  process  of  the 
nanosat.  Compiling,  organizing,  verifying  and 
providing  justifications  for  the  requirements  ensures 
that  the  design  will  meet  all  UNP  standards.  Risk 
analyses  have  been  completed  in  order  to  mitigate  and 
manage  any  potential  risks  that  can  go  wrong, 
increasing  the  likelihood  for  success  in  the  mission. 
Regular  upkeep  of  the  mass,  data,  and  cost  budgets 
have  ensured  that  the  nanosat  stays  within  the  teams 
budgets.  In  the  future,  regular  upkeep  and  adjustments 
to  the  requirements,  risk  analysis,  and  budgets  will  be 
done  to  stay  current  with  the  design. 

Thermal  Control  System 

The  thermal  subsystem  has  learned  much  in  the  past 
year  about  the  4  modes  of  operation  and  their 
importance  in  ensuring  the  survival  of  our  satellite.  In 
the  past  few  months,  we've  researched  and  sought  after 
an  understanding  of  the  many  variables  that  are 
associated  with  the  operation  of  our  satellite  such  as  the 
view  factor,  the  different  types  of  radiation,  the  thermal 
equilibrium  equation,  the  fluctuating  Albeado  and  IR 


values,  etc.  Using  the  information  we  found,  we 
performed  a  static  analysis  of  the  satellite  and 
determined  the  hot  and  cold  cases  for  a  one  node  and 
six  node  rectangle  which  haven't  been  documented  in 
an  Excel  spreadsheet.  The  most  exciting  thing  about  the 
results  we  received  from  the  six  node  rectangle  is  the 
fact  that  the  range  falls  in  a  previously  estimated  range 
from  about  a  year  ago,  which  ensures  our  team  that  we 
are  the  right  track.  The  biggest  thing  we  are  going  to 
focus  on  in  the  next  few  months  is  the  double-digit 
node  analysis,  transient  analysis  and  the  integration  of 
the  software  ESATAN  and  NASTRAN  in  our  analysis, 
and  we  are  hoping  for  continued  consistency  in  our 
data. 

The  single  and  6  node  analysis  performed  on 
ARAPAIMA  used  a  rectangular  shape  without  the  solar 
panel  configuration.  The  satellite  was  examined  using 
extreme  IR  and  Albeado  values,  resulting  in  a  hot  case 
of  -85°  ±  1°C  and  a  cold  case  of  -11°  ±  1°C  with  a 
1 1  °C  margin. 

CONCLUSION 

The  ARAPAIMA  cubesat  is  currently  at  a  preliminary 
design  review  level.  Currently,  most  of  the  subsystems 
and  budgets  are  at  a  level  from  which  we  can  proceed 
with  detailed  design  and  give  us  confidence  for  a  good 
design  at  the  critical  design  review. 
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